IEEE 1588 PTP is now the industry accepted packet-based method/standard for distributing timing information from a master to enable the clocks of distributed systems to be synchronized with high precision (in the nanosecond levels). It is also designed for applications that cannot bear the cost of a GPS receiver plus antenna at each node, or for which GPS signals are inaccessible.
IEEE1588 PTP is a two-way time transfer protocol wherein a GrandMaster clock is synchronized to a high-quality source such as GPS and then generates packets with precise timestamps that are sent downstream to slave devices. The slave devices use these timestamps as well as a delay measurement mechanism and message exchanges in order to derive the clock that is supplied to equipment requiring synchronization. Devices between the master and slave clocks may be ordinary switches and routers, or specialized equipment with on-path support, such as Boundary Clocks (BCs) and Transparent Clocks (TCs), that are intended to mitigate the effects of timing impairments introduced by the network between the master and slave.
A complete IEEE 1588-based solution includes servo (control) algorithms, filters, and PTP-clock based on hardware timer and direct timer access. The IEEE 1588 standards define a wide range of synchronization capabilities except the clock recovery mechanisms (servo algorithm, PLL, timers, etc.) to be used at the receiver (slave) to synchronize its local clock to the master. The last pieces are vendor and proprietary solutions and are often product differentiators.
Synchronization with On-Path Timing Support (ITU-T Rec. G.8275.1)
On a PTP network, frequency and time/phase (from hereon called “time” for simplicity) is distributed from a PTP master and recovered at a slave device for use by remote network equipment. The packet network between master and slave may include a number of switches or routers, which handle normal data traffic in addition to PTP traffic.
Traffic congestion, queuing effects, and quality of service (QoS) control mechanisms in the packet network between the master and slave device can cause a timing impairment such as packet delay variation (PDV), as well as delay asymmetry. PDV is the variability of delay that packets experience due to queuing and traffic conditions in the network. Delay asymmetry may be caused by a number of factors:                Different physical medium path lengths, that is, transmit/receive path differences introduced by actual fiber path differences in fiber networks or different modulation formats in microwave (MVV) and millimeterwave (MMW) links        Dynamic delay differences (queuing, congestion) between transmit and receive paths. This includes queuing and forwarding delays in network processors, traffic managers, and switch fabrics        Different network paths for transmit and receive        Rate-adaptation in the network element (as in MW and MMW base stations, DSL/GPON systems, etc.). Access technologies (like DSL) have large PDVs because of the modems adaptive transmission features to cope with line conditions. Adaptive modulation schemes in MW and MMW modems for various weather conditions further lead to large changes in link delays, possibly even asymmetric.        I/O serialization delays and speed mismatches        
This variation in delay and any asymmetry affects the quality of synchronization of the slave device. If the delay path is not symmetric, then an error in the time synchronization occurs unless the level of asymmetry is known and compensated for. It is important to emphasize that any uncompensated asymmetry in the network will directly translate to errors in the time/phase derived from the IEEE 1588 ordinary slave clock.
BCs and TCs are PTP-aware switches that provide the on-path support required to reduce the effect of PDV and delay asymmetry on a synchronization network. Networking equipment such as switches and routers may be equipped with on-path support that enable them to reduce the negative effects of PDV on a synchronization network. On-path support attempts to improve both frequency and time synchronization by minimizing or eliminating transit (dynamic) delay asymmetry in the network element, and minimizing or eliminating transit delay variation (PDV) in the network element.
There are two forms of on-path support considered in PTP (IEEE-1588):                Boundary Clock: A BC “regenerates” the timing flow. That is, a BC appears as a slave to the upstream master and synchronizes its time-clock to that master. The BC appears as a master to downstream slaves and thereby transfers its time-clock downstream. Note that a BC cannot mitigate the time error introduced by the asymmetry in the transmission medium either upstream or downstream.        BCs are PTP devices that may be positioned at a network boundary such as subnet boundary, provider edge or anywhere that a router would typically be employed. A BC has one slave port, which is connected to a Grand Master clock through the network, and it derives its frequency and time synchronization from this slave port.        The BC also has one or more master ports that are connected to slaves downstream. Sync and Follow-up packets are received on the slave port, and then the BC creates new Sync and Follow-up packets that are sent to the slave devices connected to its master ports. The timestamps included in these outgoing packets are generated by the BC using its internal PTP implementation.        Transparent Clock: A TC acts “invisibly to the master and slave from a synchronization perspective” by providing a timestamp correction term to PTP event messages traversing the TC. There are two forms of transparent clocks. The end-to-end (E2E) TC provides a correction that reflects the residence time (or dwell-time) of the packet within the equipment itself. A peer-to-peer (P2P) TC includes in the correction its own internal delay as well as an estimate of the link delay between itself and its upstream device. Neither type of TC can mitigate the time error resulting from asymmetry in the transmission medium.        
TCs are PTP devices that operate as normal switches, but they update the correction field of the PTP packets with a value equal to their residence time, that is, the time the packet was delayed in the switch (E2E TCs), or the residence time plus the peer link delay (P2P TCs). The purpose of the TC function providing on-path support is to remove the effect of PDV by informing downstream devices of precisely what these delays were on a packet-by-packet basis.
In order to make the time synchronization as accurate as possible it is important that the timestamps are as accurate as possible and that the path delay is symmetrical. BCs and TCs can be used in a network to mitigate dynamic measurable delay asymmetries but not static (fixed) asymmetries. Although BCs and TCs cannot mitigate the time error resulting from asymmetry in the transmission medium, the use of PTP allows for the compensation of known and static asymmetry in the path delays. But this of course requires that the asymmetry to be known, and that the asymmetry can be measured and is not variable so that it can be effectively compensated.
Static asymmetries could potentially be physically measured, and therefore be compensated for in software. Variable delays can be corrected in hardware on a packet-by-packet basis (using TCs). PTP on-path support in networks can largely eliminate time errors introduced by the above impairments by proper implementation of I/O-level timestamping and the use of (distributed) TCs everywhere with limited deployments of BCs for scaling purposes.
Synchronization using IEEE 1588 PTP
The IEEE 1588v2 PTP defines a packet-based synchronization protocol for communicating frequency, phase and time-of-day information from a master to one or more slaves with sub-microsecond accuracy. PTP relies on the use of accurately timestamped packets (at nanosecond level granularity) sent from a master clock to one or more slave clocks to allow them to (frequency or time) synchronize to the master clock. Synchronization information is distributed hierarchically, with a GrandMaster clock at the root of the hierarchy.
The GrandMaster provides the time reference for one or more slave devices. These slave devices can, in turn, act as master devices for further hierarchical layers of slave devices. PTP provides a mechanism (i.e., Best Master Clock Algorithm) for slave clocks to select the best master clock in their respective synchronization domain. The selection is performed according to the PTP attributes of the GrandMaster (e.g. PTP priority, clock class).
The GrandMaster is the root timing reference in a domain and transmits synchronization information to the clocks residing in its domain. In IEEE 1588v2 PTP messages are categorized into event and general messages. All IEEE 1588 PTP messages have a common header. Event messages are timed messages in that an accurate timestamp is generated at both transmission and receipt of each message. Event messages have to be accurately timestamped since the accuracy in transmission and receipt timestamps directly affects clock distribution accuracy. A timestamp event is generated at the time of transmission and reception of any event message. General messages are not required to be timestamped. The set of event messages consists of Sync, Delay_Req, Pdelay_Req, and Pdelay_Resp. The set of general messages consists of Announce, Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, Management, and Signaling.
IEEE 1588 PTP allows for two different types of timestamping methods, either one-step or two-step. One-step clocks update time information within event messages (Sync and Delay-Req) on-the-fly, while two-step clocks convey the precise timestamps of packets in general messages (Follow_Up and Delay-Resp). Each broadcast begins at time T1 with a Sync message sent by the GrandMaster to all the clocks in the domain. A clock receiving this message takes note of the local time T2 when this message is received. The master may subsequently send a multicast Follow_Up with accurate T1 timestamp.
Peer-to-Peer (P2P) Transparent Clock
An End-to-End (E2E) TC is a multi-port device that is not a master or slave clock but a bridge between the two. E2E TCs only measure the time taken for a PTP event message (Sync and Delay_Req) to transit the bridge and provide this information to the receiving clocks in the correction field. No propagation delay of the link connected to the port is corrected by the E2E TC. E2E TCs use the delay request/delay response mechanism for the delay measurement whereby the residence time of the delay request/delay response messages are corrected in the same way stated above.
A P2P TC 6 is also a multi port device that is not a master or slave clock but a bridge between the two. This clock determines the residence time of a Sync message through the switch. It also determines the inbound path (link) delay as measured using the peer delay mechanism. Both values are added up and placed in the correction field of the Sync message or associated Follow_Up message as illustrated in FIG. 1.
A PTP message arriving at the ingress port 61 is detected and timestamped by the local clock 62. The Correction Field of the arriving PTP message is read out. The P2P TC 6 calculates the link delay upstream of the P2P TC. When the PTP message reaches the egress port 63 of the TC, an egress timestamp is produced by the local clock 62. The P2P TC 6 calculates the difference between the ingress timestamp and the egress timestamp and adds the calculated link delay. This gives the residence time in the P2P TC along with the upstream peer link delay. The Correction Field is then updated by adding this value to the existing value of the Correction Field and updating the Correction Field in the outgoing PTP message accordingly.
In the end-to-end approach, delay measurement messages (Sync, Follow_Up, Delay_Req, and Delay_Resp messages) are exchanged between the master and the slave using the delay request-response measurement mechanism. In peer-to-peer networks (i.e., networks with P2P TCs) the master still sends Sync and Follow_Up messages to the slave clock just as in the end-to-end approach. A P2P TC forwards and modifies Sync and Follow_Up messages only to compensate for residence time and peer uplink delay as shown in FIG. 2. A one-step P2P TC updates for switch delay in Sync messages as they pass through the switch while a two-step TC updates a field in the non time-critical general message (Follow_Up).
The upstream link delay is the estimated packet propagation delay between the upstream neighbor P2P TC and the P2P TC under consideration. The correction field of the message received by the slave contains the sum of all residence times and link delays. In theory this is the total end-to-end delay (from master to slave) of the Sync packet, except for the delay between the last P2P TC and the slave which is added by the slave as discussed below.
P2P TCs use the following event messages for peer delay measurements: Pdelay_Req Pdelay_Resp, and Pdelay_Resp_Follow_Up. These messages are sent in the sequence shown in FIG. 3. In the peer-to-peer approach, each device on the network exchanges peer-delay measurement messages. This allows each device to keep track of the delays between itself and its immediately connected neighbors.
Each device periodically initiates an exchange of peer-delay messages on every connected port. The peer delay mechanism measures the port-to-port propagation time, i.e., the link delay, between two communicating ports supporting the peer delay mechanism. The link delay measurements are made independently by each port implementing the peer delay mechanism. This means that the link delay is known by ports on both ends of a link. This allows path length corrections to be made immediately upon reconfiguration of the network.
With this requirement and given two P2P TCs, TC1 and TC2 (FIG. 3), TC1 (upstream) initiates the peer delay mechanism to TC2 (downstream). Similarly, TC2 initiates an independent peer delay mechanism to TC1. TC2 initiates the same series of messages in the reverse direction so that both clocks know the peer-delay. However, TC2 is the TC (and not TC1) that updates the peer link delay in the Sync (or Follow_Up) message for the peer link under consideration. This is to avoid double link delay updating for a peer link under consideration. At the end of this PTP message exchange, the downstream P2P TC possesses all four timestamps {Tp1, Tp2, Tp3, Tp4}. These timestamps are then used to compute the upstream link delay.
In a peer-to-peer network, all links are periodically measured, so the delay between the master and slave are readily known when the network path/topology changes. Note that peer-delay messages are exchanged even on ports blocked to prevent loops, such as by the Rapid Spanning Tree Protocol.
As the process in FIG. 2 continues hop by hop (where N is the number of hops or links), the Sync or Follow-Up Messages maintain a running total of the residence and propagation times; resulting in a grand total delay value from master to slave:
                              total_residence          ⁢          _time          ⁢          _plus          ⁢          _propagation          ⁢          _delay                =                              d            total                    =                                                    ∑                                  i                  =                  1                                                  N                  -                  1                                            ⁢                                                          ⁢                              r                i                                      +                                          ∑                                  i                  =                  1                                N                            ⁢                                                          ⁢                              p                i                                                                        (        1        )            
Upon receipt of the final Sync or Follow-Up Message, the slave device calculates its offset. It is noted here that although the sum of the propagation and residence delays at each TC (p1, r1, p2, r2, . . . ) is included in the Sync message's associated Follow-Up's offset correction field, the final propagation delay from the last TC to the slave device must be included in order to fully capture the end-to-end delay as shown FIG. 2.
Time transfer using P2P TCs involves using the residence plus total propagation delay (in P2P TCs) at slave to mitigate PDV effects as illustrated in FIG. 4 which shows the passage of PTP timing messages 21 over a packet network 2 from a PTP master 1 having a reference clock 4 to a PTP slave 3 having a slave clock 5. P2P TCs 6 in the network 2 calculate the peer link delays and residence times for each portion of the journey except the final leg to the slave device 3. The IEEE 1588 does not describe how this should be done but left to vendor/user implementation. The standard does not specify how the clock recovery mechanism at the receiver should be implemented. The technique proposed in this document is one such mechanism for time recovery at a slave using the information accumulated in the correction field of the Sync or Follow_Up messages.
In FIG. 5, the transparent clock devices on the communication path to each slave measure the peer link delay and the delay the Sync packet resides in the TC device and increments the correction field in the PTP header. By doing so, the slave clock or boundary clock further down the line can determine how long the Sync packet resided in the TC devices before it. The slave can then use the values in the correction field to reduce the effects PDV on its path.
Consider the case where a TC contains a free-running oscillator with frequency accuracy no worse than ±100 ppm. If residence time is measured using this oscillator, there will be an error on the order of the residence time multiplied by the actual frequency offset. Optimum synchronization performance is obtained when all TCs on a synchronization path are frequency locked (syntonized) to the master clock. If a TC is not frequency synchronized to the GM, a TC with a ±100 ppm accuracy will contribute a measurement error of ±(0.0001×10 ms)=±1 μs (or ±1000 ns) to the residence time if the ideal residence time is 10 ms. A good thing is that oscillators do not typically operate at the extreme ends of their accuracy limits.
To reduce this error, IEEE 1588 Version 2 allows the TC to be syntonized, i.e., synchronized in frequency, to the GM. Each TC will use its own internal mechanisms to measure frequency offset relative to the GM and to synthesize a frequency signal that is syntonized with the GM. This synthesis may be done via hardware, firmware, or software.
Assume a network with nodes having standard Ethernet oscillators, with nominal rates of 25 MHz for 100 Mbit/s Ethernet and 125 MHz for 1 Gbit/s Ethernet. This means that the phase measurement granularity in the TC and ordinary clock can be as much as 40 ns. Additional phase error will result from the variable component of latency in the Ethernet physical layer (PHY) (the fixed component can be specified by the manufacturer in the design).
Consider the case of a syntonized TC local oscillator. If the frequency offset between the GM and TC oscillator is measured and a syntonized frequency is created, the use of this frequency for the TC delay computation will greatly reduce the magnitude of the TC measurement errors. The phase step magnitude will now be on the order of the syntonized frequency measurement accuracy multiplied by the synch interval. For example, if the phase measurement granularity is 40 ns (assuming a 25 MHz oscillator for 100 Mbit/s Ethernet) and the TC oscillator frequency offset is measured/syntonized over 100 ms, then the measured frequency offset is 40×10−9 s/0.1 s=400×10−9=0.4 ppm (parts-per-million). The TC measurement error or offset now is (400×10−9)(0.01 s)=4 ns, i.e., the TC measurement error is reduced from the 1000 ns computed when the free-running local oscillator is used for the measurement by a factor of 250. In practice, the reduction will not be this large because other effects are present, e.g., oscillator phase noise and drifts due to temperature effects, phase measurement error due to the variable portion of the PHY latency, and frequency measurement granularity.
Thus, to conclude, the timing options available for TC for delay measurements are:                Both E2E and P2P TCs: A TC uses a local free-running oscillator embedded in the TC        Both E2E and P2P TCs: A TC uses a signal that is syntonized to the GM        P2P TCs Only: A TC uses a signal that is time synchronized to the GM. The TC computes a time offset which it uses to align its clock.        
For most accurate residence time measurements, the PTP clocks in each TC should be syntonized with the GM. Syntonization only requires correction to the TC oscillator frequency. The TC host processor can use the ingress timestamps from Sync messages to determine a frequency (rate) correction required for the PTP clock. Alternatively, syntonization may be handled on the TC host processor without adjusting the frequency of the TC clocks. The frequency correction may be used to modify the computed residence times inserted into Follow_Up and Delay_Resp messages. This method may not be used with one-step operation.
The present invention aims to provide methods and devices which improve on the estimations of skew and offset of a slave clock where timing messages have passed through one or more peer-to-peer transparent clocks on the path from the master to the slave.